「转载」AI编程陷阱

原文 - 9分钟阅读

如果你曾经观察过有人“编程”，你可能会发现他们盯着空白的时间远比在键盘上打字的时间长得多。不，他们（可能）并不是在偷懒。软件开发本质上是一种解决问题的实践，因此，就像解决一个棘手的填字游戏一样，大部分工作都是在脑子里完成的。

在软件开发生命周期中，编码就是填入填字游戏的字母，相比于所有的抓头思考和潦草笔记，它只占很小一部分工作量。真正的工作通常与编码同时进行，开发者会学习业务领域、缩小需求范围、规划相关抽象、考虑副作用、增量测试功能，最后修复在这个严格过程中幸存下来的bug。它看起来像这样：

[图片：先思考，然后编码]

但在AI驱动的编程中，情况截然不同。

“先写代码，再问问题”

像Claude Code这样的AI编程代理正在让独立编写代码变得惊人地快速。但大多数软件存在于复杂的系统中，::由于LLM还不能一次性将应用程序的完整上下文保存在内存中，人工审查、测试和集成的需求仍然存在。::而当代码是在人类没有思考的情况下编写出来时，这就变得困难得多。因此，对于复杂软件而言，::大部分时间将花在事后理解AI编写的代码上。::

[图片：编码，然后试图理解]

这就是营销文案吹嘘AI编写代码的范式转换速度（通常被包装为“快10倍”）与在现实中看到的交付可工作软件的边际生产力增益（通常接近10%）之间差异的根源。

[图片表格显示编码速度vs交付速度的对比]

更令人沮丧的结果是，作为开发者，::我们花在仅仅修复这些神奇的“废话机器”输出上的时间比例越来越大。::当LLM以闪电般的速度完成所有有趣、简单的工作时，我们就被留下处理所有吃力不讨好的任务：测试以确保现有功能没有被破坏、清理重复代码、编写文档、处理部署和基础设施等等。::真正花在开发者实际喜欢做的事情上的时间很少：编码。::

幸运的是，帮助就在眼前。虽然LLM正在改变软件开发的执行方式，但这个问题本身实际上并不新。事实上，这只是一个古老问题的突出例子，我称之为：

技术负责人的困境

随着工程师在职业生涯中的进步，他们最终会踏入技术负责人的角色。他们可能在管理一个团队，或者他们可能是首席工程师，在没有人员管理的情况下推动技术交付。无论如何，他们都要对团队的技术交付负责。他们通常也是团队中最有经验的开发者：无论是在职业生涯中，在团队的专业领域中，还是两者兼而有之。

软件交付是团队努力的成果，但经验可能对个人贡献速度产生高度不平衡的影响。因此，当技术负责人的主要工作是最大化交付时，他们经常会面临两种交付软件方式之间的内在冲突：

• 公平委派给整个团队，为初级团队成员最大化学习和拥有权机会，但允许交付受到生产力最低的团队成员速度的瓶颈限制。
• 过度保护团队，只将简单或非关键的工作委派给初级员工，把最难的工作留给自己，作为团队中最能快速交付的人。

不幸的是，::虽然我们将看到过度保护对长期团队健康极其有害，但它通常也是加速交付的非常有效的方式。::技术负责人的更高带宽通常通过吃掉所有最难的工作来得到最有效的部署：

[图片：高级工程师有更高的带宽]

因此，我在职业生涯中一次又一次地看到这种模式重复。当然，这是有代价的。将经验孤立在技术负责人身上使团队变得脆弱，使支持变得更困难，并给技术负责人作为单点故障施加了越来越大的压力。接下来发生的事情是可以预测的：倦怠、离职，以及随之而来的危机，团队努力在没有那个真正知道一切如何运作的人的情况下生存。

[图片：过度保护导致短期收益但最终失败]

通常情况下，解决方案在于避免这两个极端并平衡交付与团队成长的第三条道路。我们可能将其框定为：

实施团队实践，使工程师能够在最小化返工、最大化有效协作并促进个人成长和学习的框架内交付可工作的代码。

当我担任Datasine的CTO时，我们将这种态度奉为简单的技术团队座右铭：

学习。交付。快乐。

优秀的技术负责人让他们的工程师接触到能力极限的工作，使用最小化交付风险的流程和实践，同时也使每个团队成员能够增长他们的技能、知识和领域专长。这实际上就是优秀技术领导的精髓。

::有许多方法可以实现这一点，从严格的成文框架如极限编程规则，到我们可能广义地称为“最佳实践”的较松散的原则集：::

• ::代码审查::
• ::增量交付::
• ::模块化设计::
• ::测试驱动开发::
• ::结对编程::
• ::优质文档::
• ::持续集成::

那么，对于今天的有经验工程师来说，一个紧迫的问题是：我们如何将这些实践转化到AI驱动编程的世界中？

LLM是闪电般快速的初级工程师

在2025年，许多工程师第一次发现自己处于每个技术负责人都熟悉的位置：监督一个聪明但不可预测的初级工程师。以有利于有效团队协作的方式利用和控制这种人才，是工程领导的主要挑战之一。但AI编程代理需要与初级工程师不同的管理，因为它们的生产力和成长本质根本不同。

随着软件工程师获得经验，我们倾向于同时以多种方式提高生产力：编写更健壮的代码、使用更好的抽象、花更少的时间编写和修复bug、理解更复杂的架构、更有效地覆盖边缘情况、更早地发现重复模式等等。工程是一个丰富而复杂的学科，有许多专业化的途径，但为了简单起见，我们可能将这些维度归类为两个广泛的主题：

• 质量：交付更复杂、更高性能、更可维护代码的能力
• 速度：在更短时间内开发可工作、无bug代码的能力

随着时间的推移，优秀的工程师会在这两个轴上都有所改进。

[图片：工程师和LLM在速度和质量上都有改进]

早期的LLM编写代码很快，但修复bug和消除幻觉的时间意味着它们完成无bug代码很慢。随着时间的推移，更智能的LLM和更好地使用上下文工程和工具意味着现代AI编程代理在“一次性”编写代码方面好得多。当前这一代商业可用的代理能够惊人地快速为一些会挑战中级工程师的问题产生可工作的代码，尽管它们还不能匹敌高级工程师的专长：

所以我们可以将当前这一代AI编程代理视为初级工程师，尽管有两个根本差异：

1. LLM交付代码比初级工程师快得多，不受思考时间或写作时间的限制；
2. LLM没有真正的学习能力，而只能通过更有效的上下文工程或新基础模型的到来来改进。

与初级工程人才一样，你可以有两种广泛的部署方式，取决于你的重点是长期还是短期：

• AI 驱动工程：采用最佳实践，前置人类对代码的理解，缓慢前进以使开发可持续。
• vibe coding：抛开谨慎以速度实施，为交付速度牺牲理解，最终撞上无法挽救的混乱代码墙。

正如预期的那样，在这两种方法之间选择的长期轨迹遵循与在并行委派和过度保护初级团队之间选择相同的模式：

[图片：vibe coding具有与过度保护完全相同的失败状态]

这就是为什么vibe coding方法对于小型项目或一次性原型非常棒：足够简单的应用程序可以在根本不需要任何人类思考的情况下交付。通过限制我们项目的复杂性并倚重工具的能力，我们可以立即交付端到端的可工作软件。

[图片：只要你不需要思考，vibe coding就很棒]

但你会撞上AI无法单独扩展的复杂性墙壁。

构建原型现在比以往任何时候都容易。但如果我们想有效地使用LLM来加速交付真正的、复杂的、安全的、可工作的软件，并实现超过边际效率增益，我们需要编写一个新的工程实践手册，专门为最大化包括人类和LLM在内的工程团队之间的协作而量身定制。

如何避免AI编程陷阱

AI编程代理生产力惊人，但缺乏对你的业务、代码库或路线图的深度知识。::如果不加以控制，它们会愉快地产出数千行代码，完全不顾设计、一致性或可维护性。::因此，工程师的工作就是对这些热点人物充当技术负责人：提供将原始速度转化为可持续交付的结构、标准和流程。

我们需要一个关于如何高效交付可工作软件的新手册，我们可以回顾过去来学习如何做到这一点。通过将LLM视为闪电般快速的初级工程师，我们可以依靠软件开发生命周期的最佳实践来构建可扩展的系统。

[图片：AI可以在软件开发生命周期的每个阶段使用]

就像技术负责人不只是编写代码而是为团队设置实践一样，工程师现在需要为AI代理设置实践。这意味着将AI引入生命周期的每个阶段：

规格说明：探索、分析和细化功能规格以涵盖边缘情况并缩小重点。

文档：预先生成和审查文档以提供可重用的护栏和持久证据。

模块化设计：搭建模块化架构以控制上下文范围并最大化理解。

测试驱动开发：在实现之前生成广泛的测试用例以指导实现并防止回归。

编码标准：通过上下文工程在生成代码时应用内部风格和最佳实践。

监控和内省：比任何人类都能更快地分析日志和提取洞察。

通过理解交付软件远不止编写代码，我们可以避免AI编程陷阱，反而极大地放大我们交付可工作、可扩展软件的能力。